Hugh & Brad,
Well, I think I have stumbled upon something about the 'sync input' error.  I made some minor changes to MainPanel.alt, especially in the update method to fix a problem that occurs between methods triggered by .connect and the update method.  I will go into this problem w/ you in detail when I get back, but I have a real problem w/ how long it takes to get a method to execute when a button is pushed.  For now, a simple explanation:

Desired Action:

	When Low Pressure Button is turned off, there are 2 possible actions:
		1. turn off low pressure and pumps
		2. ask operator if he wants to turn off pressure w/ parking
			frame down

In the 2nd case, the .connect method immediately turns the button back on w/ an
.initValue (NOT .setValue cuz this triggers another call to .connect method).  About 1 out of 3 times, the button off is easily detected by the update method that runs about 2 times a second, before the .connect routine can reset the button.  This seems impossible.  The button value should NEVER be changed from ON to OFF until the .connect method runs.  At 1st, I thought that it was the old double-input from click problem (THAT DID NOT GET FIXED IN LATEST ALLTALK), but .writeln statements verified that this is NOT the case.  The .connect method only ran once, but the button value was changed long before this method executed.  I did a test w/ digital outputs so I could see what is really happening.  I had the update method use a digital output to track the state
of the push-button and another digital output to signal when the .connect method actually ran.  Ooops.  Not good.  Significant delays between button turned off to when .connect method ran.  Times could easily exceed .2 seconds.  I know the Radisys is a pig and that is also a problem and is why we are getting 'sync' errors.  Both the NIED s/v controller and NTT are running >97% (99-100 most of the time) according to task manager when the scope is running.  HUD and the NIED table controller are running about 90-92%.

I was able to fix this problem by de-bouncing the update method to wait for 3 update cycles before acting in the update method.  However, when I added the change (which works perfectly on low pressure off now), we suddenly get 'sync' errors a lot today, especially when I push low pressure off.  I'd say we got 10 today.  So, I started experimenting.  Turning the scope off gets the processor down to 27% utilization and we NEVER get a 'sync' input error.  Also, turning off ALL digital input reads in the update method and letting the scope run also generates NO errors.  The s/v controller and NTT do a lot of digital input reads in the update method.  We try to do as many as possible only once at the beginning of the method, but still there are some that occur when states change.  There is NO doubt in my mind that when the processor is heavily loaded getting scope data from the DSP that requests for digital inputs cause some re-entrancy problem that crashes the communication.  Another clue to the digital
I/O is that EVERY time it happened today, I lost TOTAL control over any digital i/o== the digital inputs were reading WRONG and I could not switch any digital outputs. The digital I/O totally failed while everything else runs perfectly.  E-STOP was the only way to get the hydraulics turned off.

So, what I am going to do is radically re-vamp the update method to eliminate as much digital input reads as possible to see if it can work.  Failing that, I will back out my fix for the low pressure cuz then the error only occurs about 1-2 times/day.

At least now we know what's doing it.  I do not like the method of collecting 1 bit at a time; I think the DSP should supply all digital inputs on a slow clocked basis and alltalk should just read the latest image whenever it wants vs. going to the DSP umpteen times to get some digital inputs.  There may be a way to do this now; but I sure don't know how to do it.  All I know is getting 1 bit/statement is NOT the way to minimize traffic to/from the DSP while the scope is running.

Please do not feel that I am being hyper-critical; I have made far bigger goofs than this one.  Also, I don't think this problem would occur if we were not at the limit of the PC performance.  So, I can't blame you much.  The problem, though, is how to get by for now.  Future projects might be able to use the new Radisys Pentium product which will help future jobs; I am just concerned about NTT now cuz there have been (and still are) some catastrophic mechanical problems.  So, any s/w problem just gets blown out of proportion.  The customer's main concern is that this could occur in the middle of a test and maybe cause damage to the specimen or test measurement devices.

See if you can shed some light on this.  I could use any help you could give cuz I only have 1 more day to try things.
Rod Larson
